The invention relates to the field of application programming. In particular, the present invention relates to validating run-time references.
Large and complex systems, such as the IBM® CICS® transaction processing system, are composed of many thousands of separate and individual programs. (IBM and CICS are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide.) Each program includes source code, and the source code provides a certain type of functionality or service. In order to use this functionality, a program will make a call, invoke a function, send a message, or invoke methods against other classes (in an object orientated language) in or to the program that it needs to use.
In certain types of applications, programs are grouped into domains. A domain is a collection of programs designed to provide a particular function such as storage management or locking, for example. A domain is akin to a class in object orientated languages. Each domain provides a gate which allows other domains to invoke its services.
In order for a program to make a call to another program, a program includes declarations (references) to data structures and parameter lists which are used to invoke gates within another domain. Parameter lists are typically declared within a section near the start of a program and define the different types of parameters, options, response, and reason code fields, etc. which allow the code to make a call to other domains at runtime. These declarations include the parameter list storage area that is set up at run-time, prior to making a call to another domain, and populated upon the return from a domain call, with the various response and reason codes from a called routine within a program.
Often, programs are termed as ‘single threaded’, meaning that there is only a single thread of control running through a program at any one time. This also means that at any point in time, only one set of parameter storage is being used to handle the invocation to another domain.
It is common practice to declare different parameter list areas as overlaying each other. In a programming language, such as PLX, for example, this is achieved by defining the parameter lists as a ‘union’ of data structures, all mapping to the same starting point within a program's working storage. The ‘union’ is declared as the maximum memory size for the largest of all the parameter list areas. The advantage of this approach is that it simplifies the mapping of a program's working storage and reduces the need for larger program stack areas.
Declaring each domain's parameter list area separately means that each one will be mapped to a separate area of computer memory when the program executes. This will result in a larger program stack area and an increase in memory use. Overlaying the parameter list areas avoids this unnecessary extra storage requirement by reusing the same area in memory for each of the parameter lists.
Overlaid parameter lists are an efficient approach to better memory usage within a programming environment. However, a problem can occur when using overlaid parameter lists and not ensuring that their scope of reference is correctly managed within the source code.
Consider the case where a program invokes a call to ‘domain 1’. The program sets up the parameters in a parameter list to invoke ‘domain 1’ in a shared memory area and calls ‘domain 1’. When ‘domain 1’ has fulfilled its purpose, the flow of control of the overall program returns from ‘domain 1’ to the program. Logic is embedded within the program which can test fields, such as response and reason codes from ‘domain 1’ that have been set within the parameter list area and make run-time decisions based upon the results of the call.
However, there is no restriction on the program invoking another call (e.g., to ‘domain 2’) before testing the results from calling ‘domain 1’. The program sets up the parameters to invoke ‘domain 2’ in the shared memory area. The program then calls ‘domain 2’. When the flow of control of the program returns from ‘domain 2’ to the program, the logic can now test fields within the parameter list area as before, and make run-time decisions based upon the results of the call. The program logic tests the results of the call to ‘domain 2’, since the results are now held within the shared memory area. However, the program logic, in a different scenario, may decide to check the results of the earlier call to ‘domain 1’. However, because this information is no longer held within the parameter list area of memory (because it has been overwritten by the results of ‘domain 2’), the program logic is testing fields within the parameters set up for, or returned by, ‘domain 2’ as opposed to ‘domain 1’. This can lead to logic errors at run-time because the shared memory area does not contain the correct information.